Workflow is the operational aspect of a work procedure, namely how tasks are structured, who performs them, what their relative order is, how they are synchronized, how information flows to support the tasks and how tasks are being tracked. As the dimension of time is considered in Workflow, Workflow considers “throughput” as a distinct measure. Alternately workflow can be considered to be the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant (being a resource, human or machine) to another for action, according to a set of procedural rules.
State-of-the-art workflow systems suffer from a number of problems that make them inflexible, inadequate or prone to failure when deployed into real business or commercial environments. Two such problematic features of workflow systems are their static definition of workflow processes and their centralisation.
Current business & print workflow systems are inflexible and static once deployed. The typical approaches to definition and deployment of business and print workflow systems involve these steps: a study of the current business environment and possible definition of new, or improved workflows; selection of a workflow management product or products; transcription of the study results and any commissioned workflow process improvements into hard-coded workflow templates for utilisation by the selected product(s); customisation of workflow product features and interfacing of the product(s) and features into existing business systems; training at many levels; and deployment and switch-over to the new workflow system. At this point, a workflow process has been defined, customised and deployed and it should be adequate for the scope of tasks and contingencies recognised at the time of the defining study.
Business workflow requirements rarely remain static. There are numerous dynamic pressures on a business, including, for example, its own growth, that require a business to react appropriately and in new ways, and often in ways not anticipated in the original workflow study and definition steps. These dynamic pressures each have their own characteristics, including repetition frequencies and rates of change.
Some state of the art workflow products attempt to ameliorate these dynamic pressures, which often comprise combination-problems of change, obsolescence and contingency, by providing easier and faster methods of designing workflow templates. There exist workflow template authoring tools that may be used by the workflow product distributor, consultant or the target customer business, to customise or update workflow processes. However, these tools are offline tools, or setup tools and are intended for one-off or low frequency use and they do not significantly improve the essentially static nature of current workflow solutions.
Some workflow authoring tools provide a friendly user interface to increase the capability of understanding of a user defining a workflow template, therefore allowing the workflow authoring to be undertaken by a less-qualified person, such as a target customer employee. This kind of tool might also allow or encourage more frequent updating of the target customer's workflow template. The tools would also typically provide a (re-)deployment means for an updated or created workflow template. However, each redeployed, updated template remains static in its behaviour. Furthermore, the updating and redeployment cycle causes a need for re-training or re-documenting of workflow processes, with a large cost downstream of the update step.
A static, templated workflow process is unable to accommodate high-rate dynamic changes in a target business's activities (e.g. monthly, weekly, daily, hourly change rates or zero-notice changes). The many possible pressures for change on a business workflow can be categorised, with some examples being: internal role and resource changes; internal policy changes; external market pressures demanding internal business strategy changes (e.g. requiring a strategic redesign of prioritisation of workflow process steps, acceleration of some workflow processes, differing profiling of business processes per market or customer, etc); capital investment and internal deployment of new equipment or tools or software; business structural changes; new or modified legislation; customer or supplier business operational changes; equipment failure; internal and external financial pressures; travel or relocation of elements inside or outside a business; and so on.
Even quite minor changes in workflow processes cannot typically be accommodated by typical workflow systems. For example, a casual employee might temporarily replace a person having a role in a workflow process. In some workflow systems the insertion of this casual employee into the appropriate workflow system databases could be restrictively expensive or time-consuming, often incurring a high latency. However, this kind of change is more likely to be supported by more recent workflow systems, which may exhibit a flexibility for minor change up to a threshold, above which the workflow systems become extremely inflexible or brittle in response to change.
Other kinds of minor changes can include ‘convenience cases’ where users or customers of a workflow system desire or require some flexibility to cope with arbitrary decisions or situations. For example, if a user of a workflow process within a business wishes to or is required to execute a workflow step at a different location or device or using a different service from normal, at zero notice to the system or its administrator or manager, then this might often be impossible for a system to accommodate. Where deployed systems utilise identical computing equipment in all locations, and if a business' security & access control policies allow, a user might be able to execute his/her workflow step at any location or device. However, this homogeneity is not general, and particularly not where heterogeneous devices and services are interconnected with a workflow system or process. Homogeneity can also be expensive or constricting to a business because it can be an inefficient way to distribute and locate services.
A further example of minor changes imposed on a business workflow system is the need to invoke contingencies to cope with equipment or communications or other technology failures, again, at zero notice.
There exist many business processes that cannot be usefully described by current workflow processes or that cannot be adequately supported by current workflow systems because of their requirements for flexibility, convenience, etc. In short, the dynamic pressures on these businesses cannot be accommodated by current workflow methods.
The traditional approach to workflow is to execute workflow state machines or directed graphs (mathematical equivalents) on a central workflow engine, typically a single engine in a fixed physical and network location. The workflow engine, or server, is linked to or integrated with one or more databases containing workflow process templates, access & security information, client device & user details and possibly data materials such as documents. The centralisation of workflow systems creates several disadvantages including, a central zone of failure including the workflow engine and its subsidiary parts and core network facilities; difficulty in accommodating greater demand for computing time, memory and network bandwidths at the workflow engine, resulting in latency in workflow processing and requiring a costly machinery upgrade path; wastage of processing ability in client, subsidiary and other network computing resources, which are typically much more capable than required by the client-side tasks running on them; etc.
Some attempts have been made to reduce the workload of workflow engines or to distribute them across business boundaries or similar, or to reduce their memory needs. These methods are severely limited in their abilities and applicability and retain many of the disadvantages of a single workflow engine.
Agent-based workflow systems include many definitions of the meaning of ‘agent’ and consequently exhibit a variety of properties. There has been a successful deployment of agents within telecommunications industries, typically for automating service contract fee negotiations or billing services across commercial boundaries. Some recent agent deployments involve management, monitoring or billing for content provision services. These agent applications typically involve instantiating and executing an agent per service-instance upon one or more predetermined workflow computing nodes. That is, an agent workflow engine instance executes on one of a specially designated group of service management machines.
Some hypothesized agent-based workflow implementations allow further decentralisation of workflow execution by spawning a network-mobile workflow engine agent per workflow instance. A network-mobile workflow engine agent might travel between nodes of a network in the execution of its workflow process. This behaviour would allow partial or entire decentralisation of the workflow engine computing and memory resource demands, thus reducing some of the aforementioned problems associated with centralised workflow engines. A cost of such a network-mobile agent approach is again one of homogeneity in which all network nodes (often clients of the workflow process) would be required to support the same minimum system requirements such as including a Java® Virtual Machine, and adequate memory, cpu power, etc.
Usage-based charging methods are well-known. They have been applied to usage of tangible equipment such as photocopiers in which the usage charge is strongly linked to the quantity of copies produced. Usage-based charging has also been applied to intangible services such as content provision systems, ISPs, and even including supply of electricity, movies, and other content, etc.
A goal for vendors of services or of intangible goods is to charge accurately according to the details of the goods or services supplied to the customer, thereby giving the vendor control of its market and of its return on any transaction and giving the customer accurate information about the cost of any requested transaction.
It is also sometimes a goal of vendors of tangible equipment to attract customers to using a service linked with the equipment, to add value to the original equipment, and to provide additional return on investment in the development and production of that equipment.
Vendors may wish to specifically link properties of their products to availability and pricing of value-add services. Vendors may also wish to restrict some value-add services to be provided only for certain of their products (for instance related to level of customer investment in the vendor's products) and to close out customers of rival vendors. Vendors may also wish to have the discretionary ability to define the value-add relationship for individual market segments or individual customers from time to time.
The costs to the vendor of a value-add service may often depend on the specific details of the service undertaken. Parameters such as the quantity of operations or delivered goods are well-known parameters, but these are very limited in their ability to predict the true cost of a value-add service. For example, the cost-per-copy method of charging for copying services and for covering maintenance costs of photocopying equipment does not discriminate at all between the quality of differing jobs (such as may be set on the photocopier's control panel) or of the content of the jobs (such as may vary depending on the colour component of the job, requiring varying amounts of colour toner per job). There are some known methods of ‘guestimating’ (this term indicating that the estimate is only loosely based upon objective data) the amount of colour toner used per sheet of a copy job to allow modification of the cost-per-copy charge to the customer. There are also methods known of downloading to a customer's photocopier machine a differing charging pattern for cost-per-copy accounting.
These methods suffer from lack of accurate information and from lack of flexibility. Typically, accuracy is limited to the quantity information in a job, particularly to sheets output since this is typically the easiest and most generally applicable accounting method for print-type services or workflows. Other parameters are absent, or poorly accounted for or even guestimated, as in some prior art, providing for a very poor accounting of the true cost of a job.
A workflow process may involve a series of services followed by a goods delivery, for example a commercial printing workflow. There are known billing methods for printing processes that force a customer or retailer to tediously follow a procedure of filling parameters of the job and then the job cost is calculated according to each parameter. Although these methods force a customer or service vendor to specify additional quality parameters such as print resolution, type of print stock, number of colours, etc, these methods may still not take into account a job content parameter, for example, when accounting for the true cost. These methods would also typically be only as flexible as the vendor's job control software system allows. For instance, any special variations in a job would typically involve a guestimation or even write-off of special costs incurred because of the complexity or even impossibility of collecting accurate information to cost the job. Thus, the cost of particular components of the workflow such as ink cost, time per fold type cost, computing cost, even specialist labour cost, and so on, may remain unknown and only estimated, at best.
When a workflow process (or, more typically, processes) are undertaken largely or wholly at a customer's premises then accurate accounting becomes more complex and impractical. There is typically much less ability for a services or device vendor to control the collection and accounting of job information at a customers' site for the purposes of billing. The limitations include highly variable customer environments involving several variables such as networking setup, device and service types and versions, policies and procedures, standards, the customers' need for privacy and security for its job information, and the lack of information about the content and quality of any job, etc. In this context the service or device vendor has insufficient control to deploy and have faith in the success of a true service accounting method.